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(54) Methods, apparatus and data structures for managing objects 



(57) A variety of methods, apparatus, and data 
structuies for managing transient and persistent distiib- 
uted objects are disclosed. Objects for use as object ref- 
erences are described, both for transient and persistent 
objects. In one aspect of the invention, a data structure 
that is intended for use as an object reference for a tran- 
sient object is disclosed having a set of endpoint ad- 
dresses, an incarnation number, and an object key. 
Tnese elements serve to uniquely identify and locate the 
transient object In another aspect of the invention an 
object that is intended lor use as an object reference for 
a persistent object is disclosed having a host computer 
name, a locator identification, an object key. and a sub- 
object identifier. The first three elements serve as an in- 



direction to the persistent object and the third elemenl 
is for use by the persistent object. These data structures 
enable a distributed object operating environment which 
integrates both transient and persistent objects. A vari- 
ety of methods utilizing one or more of the elements of 
the abovementioned object references to provide a sys- 
tem resource efficient interaction between a client re- 
questing service from a server object. One particular 
method selects the fastest transport mode between the 
client and the server object Another specific method 
teaches reading addressing information directly from lo- 
cal cache memory. If the addressing information is not 
available in cache memory, the information is first found 
and then stored in cache memory thereby perpetuating 
the efficiency of the invention. 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object-oriented programming. More specifically, the 
present invention teaches methods, apparatus and data 
structures for managing transient and persistent ob- 
jects. 

Object oriented programming methodologies have 
received increasing attention over the past several 
years in response lo the growing tendency for software 
developed using traditional programming methods to be 
delivered late and over budget. This stems from the fact 
that traditional programming techniques that emphasize 
procedural models and "linear" code tend to be difficult 
to design and maintain in many circumstances. Gener- 
ally large programs created using traditional methods 
are "brittle". That is. even small changes can effect nu- 
merous elements of the programming code. Thus, minor 
changes made to the software in response to user de- 
mands can require major redesign and rewriting of the 
entire program. 

Object oriented programming strategies tend to 
avoid these problems because object methodologies fo- 
cus on manipulating data rather than procedures thus 
providing the programmer with a more intuitive ap- 
pioach to modeling real world problems. In addilion ob- 
jects encapsulate related data and procedures so as to 
hide that information from the remainder of the program 
by allowing access to the data and procedures only 
through the object's interface. Hence changes to the da- 
ta and or procedures of the object arc relatively isolated 
from the romainaer of the program. This provides code 
that is more easily maintained as compared to code writ- 
ten using traditional methods, as changes to an object's 
code do not affect the code in the other objects In ad- 
dition, the inherent modular nature of objects allows in- 
dividual objects and interfaces to be reused in different 
programs. Thus, programmers can develop libraries of 
"tried and true" objects and interfaces that can be used 
over and over again in different applications. This in- 
creases software reliability while decreasing develop- 
ment time, as reliable programming code may be used 
repeatedly. 

A more recent advance in the field of object oriented 
methodologies has been the implementation of distrib- 
uted object operating environments over computers in- 
terconnected via a computer network. As used herein, 
the term "distributed object" or "object" refers to an en- 
capsulated package of code and data that can be ma- 
nipulated by operations through an interface. Thus, dis- 
tributed objects will be seen by those skilled in the art 
of object oriented programming (OOP) as including the 
basic properties that define traditional programming ob- 
jects. However, distributed objects differ from traditional 
programming objects by the inclusion of two important 



features. First, distributed objects are multilingual. That 
is. the interfaces of distributed objects are defined using 
an interface definition language (IDL) that can be 
mapped to a variety of different programming languag- 
5 es. One such interface definition language is the Object 
Management Group's IDL. Second, distributed objects 
are location-independent, i.e.. distributed objects can 
be located anywhere in a network. This contrasts sharp- 
ly with traditional programming objects which typically 
to exist only in a single address space which is shared with 
the their clients. 

Distributed objects can be object clients or object 
servers, depending upon whether they are sending re- 
quests to other objects or replying to requests from cli- 
'5 enls. In a distributed object environment, requests and 
replies are made through an Object Request Broker 
(ORB) that is aware of the locations and status of the 
objects. One architecture which is suitable for imple- 
menting such an ORB is provided by the Common Ob- 
20 ject Request Broker Architecture (CORBA) specifica- 
tion. The CORBA specification was developed by the 
Object Management Group (OMG) to define the distrib- 
uted computing environment world in terms of objects 
in a distributed client-server environment, where server 
-5 objects are capable of providing services to clients re- 
questing the service. In the following discussion, the 
terms "object" and "distributed object" will be used in- 
terchangeably. 

In the lield of distributed ooject enviionmenls. there 
30 are potentially two predominant kinds of objects, the 
transient object and the persistent object. Transient ob- 
jects typically have a short life span and are bound to a 
single host process That is when a host process ceas- 
es, all transient objects running under the process also 
5$ cease. Thus there is no continuity of identity of a tran- 
sient object from one process to another Because tran- 
sient objects are bound lo a single process they inher- 
ently cannot change their, location Hence transient ob- 
jects could also be renamed "immobile" objects, as their 
-*o addresses never change. 

In contrast, persistent objects are not bound to a 
single process and their location may change over lime. 
Thus persistent objects could be called "mobile" objects, 
as their addresses may change. With a persistent ob- 
4S ject. there is continuity of ioentity from one process to 
another However, a persistent object can exist in only 
one process at a time. 

When discussing the transient or persistent nature 
of an object what is typically being envisioned is the 
50 transient or persistent nature of the object state. As will 
be well familiar to those skilled in the art. a computer 
entity such as a process or an object may have two com- 
ponents: executable code and state. Executable code 
is essentially the instructions by which the entity oper- 
55 ates. Thus state is the remaining portion such as data 
which is not code. The motivation behind different kinds 
of state, e.g transient and persistent is fairly straight 
forward. Persistent state requires additional system re- 
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sources such as mass-slorage devices and correspond- 
ing management resources to ensure persistence, 
which may or may not be desired. For example, infor- 
mation stored in a database is typically intended for long 
term storage, and thus persistence is required. In situ- * 
ations such as this it is well worth the extra system re- 
sources required to maintain this data. 

However, there are a variety of scenarios where 
persistence is not required and thus the extra system 
resources required for persistent state are in effect wast- 10 
ed. Any situation where the state is necessary only for 
a short period and/or if needed later can be easily rec- 
reated is a candidate for transient state. A familiar ex- 
ample of this is icons such as formatting and editing but- 
tons in many window based word-processing programs. '5 
When implementing buttons such as these, there will be 
(roughly speaking) code which makes them operate and 
state which gives them their appearance. This state 
would include the bit map of the icon. When the word- 
processing window is closed, the icon disappears and 20 
there is no need to maintain the bit map of the diflerent 
icons. By using transient state, the system can forget 
abcut maintaining these bit maps until they are needed 
again, at which time they can be recreated. 

Prior solutions for dealing with transient and/or per- 25 
sisteni state fail to provide a framework which effectively 
enables the integration of transient and persistent ob- 
jects within a distributed object operating environment. 
F01 example, database technology, including object ori- 
ented database technology, has generally dealt only 30 
with maintaining persistent slate. As another example, 
personal computing systems are designed so that all re- 
sources and services start up the same each time by 
utilising persistent state The well known Distributed 
Computing Environment (DCE) implements only per- ~5 
sisteni distributed objects, using a 129 bit identifier lo 
manage each individual object. In general, prior tech- 
nology deals mostly with persistent objects and if it does 
deal with transient objects, it tends to focus on only tran- 
sient objects What is needed is a framework for effi- -*o 
ciently integrating transient and persistent objects under 
a distributed object operating environment. This will re- 
quire data structures which will allow for the differences 
between the two yet still provide an integrated frame- 
work. Moreover, effective methods for managing these 
persistent and transient objects will be required 

SUMMARY OF THE INVENTION 

To achieve the foregoing and other objects and in so 
accordance with the purpose of the present invention, 
methods, apparatus, and data structures for managing 
transient and persistent objects are described. In one 
aspect of the invention, a data structure which is intend- 
ed for use as an object reference for a transient object 55 
includes a set of endpomt addresses, an incarnation 
number, and an object key. The set of endpoint address- 
es is arranged to correspond to a server host computer 
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upon which the transient object resides. The incarnation 
number is arranged to correspond to a server hosl proc- 
ess which is executing on the host computer. The tran- 
sient server object may run only in this server host proc- 
ess. The object key is an identifier which corresponds 
to the transient server object. These three elements, the 
set of endpoint addresses, the incarnation number, and 
the object key T serve to uniquely identify and locate the 
transient server object. Additionally, various embodi- 
ments and a variety of methods for utilizing one or more 
of these elements to enable efficient interaction be- 
tween a client requesting services and the transient 
server object are also described. 

In some applications the length of these data ele- 
ments may be variable, whereas in other applications 
the length may be fixed. In the fixed case, a length in 
the range of about 1-1 28 bytes is preferred. In one par- 
ticular embodiment, one address from the set of end- 
point addresses includes a 4 byte long server host net- 
work address and a 2 byte long server process network 
port number. In another particular embodiment, the in- 
carnation number is essentially a date stamp. That is a 
monotonically increasing number indicating the creation 
time of the server process. In other embodiments, the 
incarnation number is a predefined number which has 
a predefined meaning to the server process. 

In one specific embodiment, the object key is an 
identification number unique within the server process 
that hosts the transient server objecl. In yet another em- 
bodiment, the object key is used to transport an object 
reference which is formatted according to the protocol 
of a different distributed object operating environment. 

According lo another aspect of the present inven- 
tion the data structure of the object reference includes 
an internal name indicating that the object kind is tran- 
sient 

In another aspect of the invention, a transient object 
corresponding to the abpvementioned object reference 
is contemplated The transient object has state, but this 
state is strictly transient state. In further embodiments 
the transient object is bound to the server process and 
therefore has continuity of identity within and only within 
the server process. 

In a apparatus aspect of the invention, a distributed 
objecl operating environment includes a plurality of 
computer systems, a computer network interconnecting 
the computer systems, and at least one object for use 
as an object reference for a transient server object. In a 
further apparatus embodiment, the distributed object 
operating environment also includes a second object for 
use as an object reference for a persistent server object. 
The second object has a data structure which includes 
a host computer name, a locator identification, an object 
key. and a subobject identifier. The second object's data 
structure may optionally include a location hint and a 
kind field which indicates that the object kind is persist- 
ent. 

In the data structure of the second object, the host 
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compuler name will correspond lo a hosi computer 
which has a servei object locator service running on it. 
The locator identification will correspond to a process 
within which a server object locator object exists. The 
locator object is one component of a locator service, the s 
locator object being consulted to establish location in- 
formation for the second object. The location informa- 
tion will include data similar to the first object data struc- 
ture such as a set of endpoint addresses and an incar- 
nation number. 70 

In separate aspects of the invention, various meth- 
ods of managing transient and persistent objects during 
the calling of a distributed server object which runs on 
a server process residing on a server host computer are 
described. In one method aspect, the client has an ob- 
ject reference to a server object and the client call in- 
cludes the steps of acquiring addressing information for 
the distributed server object, selecting an address for. 
the distributed server object and sending a request to 
the distributed server object. In a further embodiment 20 
this method includes the step of receiving a response 
from the distributed server object. 

In another method aspect, the step of acquiring ad- 
dressing information includes the substep of determin- 
ing the kind of the distributed server object, the kinds 25 
including transient persistent, null, and invalid. Then, 
depending on the kind of the distributed server object, 
different methods may be performed. If the kind is null 
01 invalid, an enoi message is lelurned. If the kind is 
transient, then addressing information is returned direct- 00 
ly from (he object reference. If the kind is persistent, then 
the step of acquiring addressing information includes 
further steps such as determining if the addressing in- 
formation is stored in cache memory on the client host 
computer and returning the addressing information di- 3fi 
rectly from the cache memory. If (he addressing infor- 
mation is not stored in cache memory (hen the address- 
ing information is obtained from within the distributed 
object operating environment, stored in cache memory, 
and then returned directly from the cache memory. -*o 

In a further method aspect, the step of selecting an 
address includes determining if said client and said 
server are in the same process, and if so. a local address 
and a local transport mode are selected. In another 
method aspect, if the client and server are in different -*s 
processes, shared memory addressing and shared 
memory transport are selected if the server host com- 
puter is the same as the client host computer. However, 
if shared memory addressing is not available or if the 
server host computer is not the same as the client host so 
computer, then remote addressing and remote transport 
is selected. 

In a separate method aspect, a method for main- 
taining distributed object addressing information in a 
cache memory on a host computer in a distributed object ss 
operating environment is disclosed. This method begins 
when an object reference corresponding to a distributed 
object is received. Then, if the object reference includes 



addressing information for the distributed object, this ad- 
dressing information is written into the cache memory. 
In some embodiments the object reference is received 
as pan of a target object call, while in other embodi- 
ments it is received in response to a target object call. 
In any event, the step of receiving may include unmar- 
shaling the object reference prior to determining if any 
addressing information is available. 

In a method aspect related to the preceding para- 
graphs discussion, a multiplicity of host computers 
which are part of a distributed object operating environ- 
ment each have their own cache memory. Each of these 
computers performs the method of the preceding para- 
graph in order to increase the addressing information 
available in their cache memory. Furthermore, if any of 
the host computers locates new addressing information, 
it perpetuates the advantages of the present invention 
by marshaling it into an object reference and distributing 
it to the other host computers which are part of the dis- 
tributed object operating environment. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with further objects and ad- 
vantages thereof, may best be understood by relerence 
lo the following description taken in conjunction with the 
accompanying drawings in which: 

FIGURE 1 is a piclonal illustration of various com- 
puters linked together in a computer network 

FIGURE 2 illustrates diagramatically the major 
components of a computer in Figure 1 . 

FIGURE 3a is a pictorial illustration of a hosl-to-host 
client-server model showing the relationship be- 
tween a client running on a client host computer anc 
hi server object running on a different server host 
computer in a distributed object operating environ- 
ment; 

FIGURE 3b is a pictorial illustration of a process-to- 
process client-server model showing the relation- 
ship between a client and server running in different 
processes on a client/server host computer; 

FIGURE 3c is a pictorial illustration of a client-server 
model showing the relationship between a client 
and server running in a single client/server process: 

FIGURE 4a is a pictorial illustration of a persistenl 
object showing a progression through three differ- 
ent object states each state including transient 
state and persistent state in accordance with a first 
aspect of the present invention: 

FIGURE 4b is a pictorial illustration of a transient 
object in accordance with a second embodiment of 



BNSDOCID:<EP 0737916A1 I 




7 EP 0 737 

ihe presenl invention showing a progression 
through three different states, each state including 
transient state in accordance with a second aspect 
of the present invention: 

5 

FIGURE 5a is a pictorial illustration of an object ref- 
erence for a transient object, the object reference 
including a kind field, a set of endpoint addresses, 
an incarnation number, and an object key in accord- 
ance with a second embodiment of the present in- io 
vention: 

FIGURE 5b is a pictorial illustration of an object ref- 
erence for a persistent object, the object reference 
including a kind field, a host name, a locator identi- '5 
fication. an object key. a subobject identifier, and a 
location hint in accordance with a first embodiment 
of the present invention: 

FIGURE 6 is a flow chart illustrating a process ex- 20 
ecuted by a client to invoke a distributed server ob- 
ject in accordance with one method aspect of the 
present invention: 

FIGURE 7 is a flow chart illustrating in further detail ^5 
a step 504 of FIGURE 6: 

FIGURE 8 is a flow chart illustrating in further detail 
a step 506 of FIGURE 6. 

DO 

FIGURE 9 is a flow chart illustrating in further detail 
a step 716 of FIGURE 7: 

FIGURE 10 is h flowchart illustrating in further detail 

a step 904 of FIGURE 9: and ^ 

FIGURE 1 1 is a flow chart illustrating a process for 
perpetuating the advantages of the preseni inven- 
tion by increasing the addressing inlormation avail- 
able in cache memory 40 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention relates to a distributed oper- 
ating environment based on object oriented program- 
ming (OOP). More specifically, this invention discloses 
methods, apparatus and data structures for managing 
objects. The kinds of objects which are discussed in- 
clude transient and persistent objects. A transient object 
maintains no persistent state and is tied directly to the 
life of the process under which it is running. By way of 
explanation, persistent state is that stele which persists 
(or bridges) from one process to another. On the other 
hand, a persistent object can have both persistent and 
transient state and typically persists over a length of 
time. In the following discussion, the diflerent kinds of 
objects will be described in more detail first through dis- 
cussing example computer systems which are suitable 
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for the present invention, next continuing with a detailed 
description of several embodiments of the apparatus 
and data structures of the present invention, and then 
further through the detailed description of the method 
aspects of the present invention. 

I. DEFINITION OF TER MS 

As used herein, the term "distributed object" or "ob- 
ject" refers to an encapsulated package of code and da- 
ta that can be manipulated by operations through a de- 
fined interface that is associated with an object. Thus, 
distributed objects will be seen by those skilled in the 
art as including the basic properties that define tradition- 
al programming objects. However, distributed objects 
differ from traditional programming objects by the inclu- 
sion of two important features. First, distributed objects 
are multilingual. The interfaces of distributed objects are 
defined using an interface definition language that can 
be mapped to a variety of different programming lan- 
guages. One such interlace definition language is OMG 
IDL. Second, distributed objects are location-independ- 
ent, i.e.. distributed objects can be located anywhere in 
a network. This contrasts sharply with traditional pro- 
gramming objects which typically exist in a single ad- 
dress space the address space of the "client." Distrib- 
uted objects can be object clients or object servers de- 
pending upon whether they are sending requests to oth- 
ei objects or leplying to requests fiorn other objects Re- 
quests and replies are made through an Object Requc-st 
Broker (ORB) that is aware of the locations and status 
of the objects. 

A "distributed object system" or "distributed object 
operating environment" refers to a system comprising 
distributed objects that communicate through an ORB 

An "object reference" or "objref" is data structure (il 
may be a traditional programming language object) that 
contains a pointer to another object The creation anc 
delinitton of object references will be familiar to those 
skilled in the art. 

A "client" as defined herein refers to an entity that 
sends a request to an object. In this model, the object 
provides a service and is referred to as a "server object" 
or a "target object". Thus, clients invoke operations or 
implementations, from servers. In some cases, clients 
are themselves objects. In a distributed object environ- 
ment, clientsneednot have knowledge of the implemen- 
tation programming language, nor does the implemen- 
tation have to have knowledge of the client's program- 
ming language due to the requirement of multilingual 
character of such objects. Clients and servers in distrib- 
uted object operating environments need only commu- 
nicate in terms of the interface definition language. As 
noted above the request by the client to the server, and 
the server's reply to the client, is handled by the ORB. 
It should be pointed out that the client and server can 
exist within the same process, on the same host com- 
puter, or on two different host computers. 
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An "object interface" is a specification of the oper- 
ations, attributes, and exceptions that an object pro- 
vides. Preferably, object interfaces for distributed ob- 
jects are written using an IDL. As noted above, objects 
perform transactions through their interfaces. The use 
of interlaces therefore eliminates the need of clients to 
be aware of the programming languages used to define 
the methods and data of the objects in the transaction. 

To "marshal" a packet of information is to prepare 
this informatfon for transfer either through a shared 
memory communications channel or over a network 
communications line. This often means organizing the 
data in a particular format in accordance with the com- 
munications protocol being used. 

To "unmarshal" a packet of information is to essen- 
tially reverse the marshaling procedure and produce da- 
ta in a format which is meaningful in the appropriate en- 
vironment. 

II Managing Objects 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object-oriented programming. More specifically, the 
present invention teaches methods, apparatus and data 
structures for managing transient and persistent distrib- 
uted objects. 

As used herein, the term "distributed object" or "ob- 
ject" leleis to an encapsulated package of code and da- 
ta that can be manipulated by operations through an in- 
terface. Additionally, the distributed object of the present 
invention may include features such as described in the 
background. For example, distributed objects can be 
object clients or object servers, depending upon wheth- 
er they are sending requests to other objects or replying 
to requests from clients. 

In a distributed object environment, requests and 
replies are made through an Object Request Broker 
(ORB) that is aware of the locations and status of the 
objects. One architecture which is suitable for imple- 
menting such an ORB is provided by the Common Ob- 
ject Request Broker Architecture (CORBA) specifica- 
tion. The CORBA specification was developed by the 
Object Management Group (OMG) to define the distrib- 
uted computing environment world in terms of objects 
in a distributed client-server environment, where server 
objects are capable of providing services to clients re- 
questing the service. In the following discussion, the 
terms "object" and "distributed object" will be used in- 
terchangeably, as the following invention is directed to 
both types. 

In a preferred embodiment of the present invention, 
distributed objects are located on one or more comput- 
ers linked together by a network. The network may take 
any suitable form. By way of example a representative 
network arrangement 10 is illustrated rn Fig. 1 . The net- 
work arrangement 1 0 includes a first computer 1 2 which 
is coupled to a transmission line 14. The network 10 fur- 



ther includes a server, router or the like 16 in addition to 
other computers 18. 20. and 22 such that data and in- 
structions can be passed among the networked comput- 
ers. The design, construction and implementation of 
5 computer networks will be familiar to those of skill in the 
art 

A representative computer 30 suitable for use as 
computers 12. 18. 20. and/or 22 of Fig. 1 is illustrated 
schematically in Fig. 2. Computer 30 includes a central 
to processing unit (CPU) 32 which is coupled bidirection- 
al!^' with random access memory (RAM) 34 and unidi- 
rectionally with read only memory (ROM) 35. Typically. 
RAM 34 is used as a "scratch pad" memory and includes 
programming instructions and data, including distribut- 
es ed objects and their associated code and state, for proc- 
esses currently operating on CPU 32. Note thai tran- 
sient stale is often stored in transient memory such as 
RAM 34. ROM 36 typically includes basic operating in- 
structions, data and objects used by the computer to 
20 perform its functions. In addition, a mass storage device 
36. such as a hard disk. CD ROM. magneto-opticai (flop- 
tical) drive, tape drive or the like, is coupled bidirection- 
ally with CPU 32. Mass storage device 38 generally in- 
cludes additional programming instructions, data and 
? 5 objects that typically are not in active use by the CPU. 
although the address space may be accessed by the 
CPU. e.g.. for virtual memory or the like. Note that per- 
sistent state is often stored in persistent memory such 
as storage device 36 Each of the above described corn- 
30 puters optionally include input/output sources 40 that 
typically include input media such as a keyboard, pointer 
devices {e.g.. a mouse or stylus) and/or network con- 
nections Additional mass storage devices (not shown) 
may also be connected to CPU 32 through a network 
~5 connection it will be appreciated by those skilled m the 
art that the above describee hardware and software el- 
ements, as well as networking devices, are of standard 
design and construction, and will be well familiar tc 
those skilled in the art ' 
40 Returning to the discussion of the client and server, 
one of the underpinnings of distributed object environ- 
ments is the interaction between the client, which is de- 
fined herein as an entity requesting a service, and a 
server, which is typically an object providing the service 
J 5 For example, different scenarios include the client and 
server within the same process, in different processes 
on the same host computer, and on different processes 
running on different host computers. This client-object 
interaction can be discussed in terms of a client-server 
50 model. By way of example, a client may be in a process 
running on a network computer, such as computer 12. 
which requests services from a server object in a differ- 
ent process running on a remote computer 18. 

As will be appreciated by those of skill in the art. the 
55 entities which can be a client include, but are not limited 
to. a process running on a host computer, hereinafter 
referred to as a client process and client host respec- 
tively, and an object, hereinafter referred to as a client 
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object. Therefore, a clieni is an entity requesting a serv- 
ice, regardless ol the type of entity For the sake of clar - 
ity, the object providing the service is hereinafter re- 
ferred to interchangeably as a target object or a server 
object. Thus in the following description, when a client 
invokes a target object, the client may be any entity such 
as a client process or a client object. 

Elaborating further on the terminology of client- 
server interactions a client will "call" a target object to 
"invoke" a "method" that is executed by the target object. 
Note that while "call" and "invoke" can carry slightly dif- 
ferent meanings, herein the two terms are used inter- 
changeably and their meanings will be understood from 
the context of the discussion herein. As is well known to 
those of skill in the art. a method is a procedure con- 
tained within an object which is made available to other 
entities, i.e clients for the purpose of requesting serv- 
ices of that object. Thus the object performing the serv- 
ice for the client is the server, hence the phrase client- 
server. In calling a method, the client may also pass 
those arguments, also referred to as parameters, nec- 
essary for the target object to perform the requested 
method. Please note that the previous term "method" is 
a term of the art of object oriented programming and dif- 
fers from the term "method" classically used in drafting 
patent applications. In the following discussion, the Ap- 
plicant believes that it is made clear (either by context 
or by a hint from the Applicant) which meaning for the 
leim "method" is used. 

Referring next to Figs. 3a - 3c. a few possible enu- 
merations of a client-server model that are very repre- 
sentative oi a distributed object environment will be dis- 
cussed As is always the case, the client-server model 
will have a client entity and a target object which is the 
server entity. One such arrangement for the following 
client-server models includes computers such as com- 
puter 30 of Fig. 2 interconnected over a network 14 as 
shown in Fig 1 

Turning first to Fig 3a. a client-server model 300 
termed "host-to-host" is shown wherein clieni 302 and 
target object 304 exist on different host computers within 
a distributed object operating environment 301 . The cli- 
ent 302 exists in a client process 306 which is running 
on a client host computer 308. Client 302 uses a first 
surrogate object 310 which holds {e.g. it has a first indi- 
rection 312 to) an object reference 314. In turn, object 
reference 314 provides a second indirection 316 to the 
target object 304. As used herein an indirection to an 
object is simply enough information to locate the object, 
although perhaps not by way of direct interaction with 
the object. In the case of Fig. 3a. the first indirection 312 
is typically just a direct pointer to the object reference, 
while the second indirection 31 6 is often more elaborate. 
Indirections such as indirection 316 will be discussed m 
more detail later with respect to Figs. 5a and 5b. Addi- 
tionally, there may be other surrogate objects present in 
the client process 306. such as second surrogate object 
311. which may also hold the object relerence 314. In 
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some cases surrogate objects 310 and 31 1 may be tra- 
ditional programming language objects. However some 
distributed object operating environments do not include 
surrogate objects. In these cases, the client 302 will uti- 

s lize the object reference 31 4 without a surrogate object. 
Similar to the client 302. the target object 304 of Fig. 
3a can exist in a server process 318 which is running 
on a server host 320. Other entities may be resident on 
both the server host 308 and the client host 320. These 

to include but are not limited to additional processes and/ 
or objects running under the client process, the server 
process, and/or the additional processes. Two suitable 
processes are daemon_l process 31 7 running on client 
host 308 and daemon 2 process 321 running on server 

75 host 320. Daemon processes typically run in the back- 
ground and are well known to those skilled in the art. 

As Fig. 3a illustrates, in the host-to-host case, client 
302 must pass its call to the target object 304 through 
several "layers", i.e. complexities not directly related to 

20 the service requested of the target object. In the host- 
to-host example, a network connection must be estab- 
lished between the client 302 and the target object 304. 
Because of the differeni layers such as the client and 
server hosts 308 and 320 and the client and server proe- 
ms ess 306 and 318. the client-server network connection 
can not be established directly. Rather, the client proc- 
ess 306 must interpret tne call, and pass this on to the 
surrogate object 310 which may use the ORB to first linti 
the server host 320 and then identify the server piocess 

oo 316 and target object 304 Furthermore, as this data is 
being communicated over the network, this data must 
be marshaled {i e formatted according to the network 
communications protocol so as to prepare it for trans- 
mission over the network), sent, received, and linally un- 

~£ marshaled. Thus hosl-to-host is a complicated case of 
the client-server interaction Accordingly, the additional 
layers and resultant steps make the host-to-host client- 
server interaction often the most expensive possible in- 
teraction in terms of system resource utilization 

•*o Fig. 3b shows a "process-lo-process" client-server 

model in which the client 302 and the target object 304 
share the same host computer, a client/server host 322. 
However, client 302 and target object 304 reside within 
different processes. Similar to Fig. 3a. the client 302 ex- 
ists in a client process 306 which is running on the client/ 
server host 322 The client 302 uses a first surrogate 
object 310 which holds {e.g. it has a first indirection 312 
to) an object reference 31 4. In turn, object reference 314 
provides a second indirection 316 to the target object 

so 304. Target object 304 exists within in a server process 
31 8 which is running on the client/server host 322. Akin 
to the "host-lo-host" case, further entities such as proc- 
esses and/or objects may be resident on client/server 
host 322. For example, there may be other surrogate 

ss objects present in the client process 306. such as a sec- 
ond surrogate object 311. which may also hold the ob- 
ject reference 314. However some distributed object op- 
erating environments do not include surrogate objects. 
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In these cases, the client 302 will utilise the object ref- 
erence 31 4 without a surrogate object. In any event, the 
process-to-process interaction may be significantly bet- 
ter than the host-to-host interaction. This is, in part, be- 
cause the network communication steps are unneces- s 
sary. 

Fig. 3c shows a client-server model in which both 
client 302 and target object 304 reside within the same 
process, the client/server process 324 Once again, the 
client 302 uses a first surrogate object 310 which holds to 
(e.g. it has a first indirection 31 2 to) an object reference 
314, In turn, object reference 314 provides a second in- 
direction 316 to the target object 304 In this case the 
second indirection 316 may just be a pointer to shared 
memory. This situation is perhaps the best of all three ^ 
described cases. No network communications is neces- 
sary, and since both objects are under one process, they 
coexist in memory allocated to the client/server process 
324. In the situation of Fig. 3c. other entities such as 
objects may be resident in client/server process 324. 20 
For example, there may be other surrogate objects 
present in the client process 306. such as a second sur- 
rogate object 311. which may also hold the object refer- 
ence 314. However some distributed object operating 
environments do not include sunogate objects. In these 25 
cases, the client 302 will utilize the object reference 314 
without a surrogate object. 

Two other typical client-server scenarios which ate 
not shown in the above desci ibed Figs, will now be dis- 
cussed briefly. The first scenario involves the embodi- 00 
ments wherein the client is an object. As will be appre- 
ciated by those of skill in the art. the issues which arise 
are very similar (often identical) whether the client is an 
object or some other entity requesting service Thcothcr 
scenario is one wherein the client object and the target sf> 
object are the self-same object. This may occur when 
an object makes a recursive call upon itsell While the 
recursive call may appear unusual this client-server in- 
teraction is a fairly common and powerful tool and may 
be dealt with in a manner similar (or perhaps identical) -to 
to the case wherein a client object and a target object 
are unique but exist in the same process. 

Fig. 4a shows the progression of a persistent object 
401 through three different states. The first transition 
40C brings the persistent object 401 from a previous •*$ 
state into state 1. State 1 of object 40i includes both 
transient state 402 and persistent state 404. Transition 
406 brings the persistent object 401 from state 1 into 
state 2. Similar to state 1 . state 2 of object 401 has both 
transient state 408 and persistent state 410. Finally, so 
transition 41 2 brings the persistent object 401 from state 
2 into state 3. Once again, state 3 of object 401 has both 
transient state 414 and persistent state 416. For the per- 
sistent object 401 . the transitions 400, 406. and 412 can 
be any operation which changes the state of the object ss 
401 . including the termination of a process under which 
the object exists. Because the persistent object includes 
persistent state at each stage, it has the capacity to 



bridge from process to process and maintain itself for 
long periods of time. 

In contrast. Fig. 4b show the progression of a tran- 
sient object 417 through three different states. The first 
transition 416 brings the transient object 41 7 from a pre- 
vious state into a state A. State A of transient object 417 
includes transient state 420 but does not include any 
persistent state. Transition 422 brings the transient ob- 
ject 417 from state A into a state B. Similar to state A. 
state B of transient object 417 has transient state 424 
and does not have any persistent state. Finally, transi- 
tion 425 brings the transient object 41 7 from state B into 
a state C. Once again, state C of transient object 417 
has transient state 428 and does not have any persistent 
state. For the transient object 417. the transitions 418. 
422. 426 can be any operation which changes the state 
of the transient object 417. with the exception of opera- 
tions which include cessation of the process under 
v/hich the transient object 41 7 exists. Because the tran- 
sient object 417 does not include persistent memory, it 
cannot bridge across processes. Therefore transient 
objects exist in one and only one process and cease to 
exist when the process ceases. Additionally, note that a 
process' location and address cannot change, therefore 
a transient object's location and address cannot 
change. 

From the above discussion of the client-server mod- 
el and the relationship to transient and persistent ob- 
jects, it should be apparent that frameworks for handling 
client-server interactions efficiently and flexibly are pre- 
ferred One framework which provides apparatus and 
data structures will now be discussed. 

In order to facilitate the aforementioned client-serv- 
er interactions, distributed object operating systems (in- 
cluding the distributed architecture specitied by COR- 
BA) typically incorporate an object termed an "object ref- 
erence " Object references serve both to locate and to 
identify the target objects of individual operation re- 
quests, as well as to provide general parameters of op- 
eration. Because of the differences in dealing with the 
different kinds of objects, there are no teachings in the 
prior art which incorporate both transient and persistent 
objects under the same framework. However, the teach- 
ing of the present invention includes a framework for use 
within a distributed object operating environment which 
integrates both transient and persistent objects. One 
embodiment incorporating transient object references 
and persistent object references will be discussed later 
in more detail. 

As object references direct a client to their corre- 
sponding target object, there is another meaningful way 
of looking at the adjectives "transient" and "persistent" 
as used to modify the term "object reference " Persistent 
object references are an indirection (they locate and 
identify) to a distributed object which has continuity of 
identity. Therefore, the indirection of a persistent object 
reference is a persistent indirection as it is always valid 
(unless the identity of the persistent object is destroyed). 



BNSDOCID: <EP 073791 6AiJ_> 



15 



EP 0 737 916 A1 



In contrast, transient object references are a direction 
to a distributed object which has no continuity of identity. 
Tnerefore. the direction of a transient object reference 
is a transient direction. 

In addition to transient and persistent object refer- 
ences there arc two additional kinds of object references 
which should be mentioned. The first is a "null" object 
reference and the second is an "invalid" object refer- 
ence. Similar to transient and persistent object referenc- 
es, null object references and invalid object references 
correspond to null and invalid objects A null object may 
be an object which does not have an interface, or is in 
a state in which it will not serve clients. In preferred em- 
bodiments the null object reference is supported and 
therefore may be coded. An invalid object is typically a 
nonexistent or ill-formed object and is usually not sup- 
ported. Therefore a invalid object may typically not be 
coded. 

Fig. 5a shows a pictorial illustration of a data struc- 
ture for a transient object reference 500 in accordance 
with one embodiment of the present invention. The ob- 
ject reference 500 includes an kind field 501. a set of 
endpoint addresses 502. an incarnation number 504. 
and an object key 506. In preferred embodiments, kind 
tield 501 is a data element which represents the object 
kind to which object relerence 500 indirects. In otner em- 
bodiments, the kind tield 501 is not included in the object 
reference 500 and the object kind is determined by the 
distinguishing fealuiesof the data sliuctuie of the object 
reference 500. That is. the object kind to which an object 
reference indirects can be determined uniquely by the 
data structure of the object reference 

Continuing the discussion of Fig 5a. the set ot end- 
point addresses 502 includes addressing information 
necessary for a client to locate the server host and serv- 
er process in which the target object may exist. This in- 
formation may include elements such as the server host 
network address the server process network port 
number, and/or the memory location of the target object 
Furthermore, the set of endpoint addresses may include 
a plurality of addresses, each of which may be valid. The 
set of endpoint addresses may include a variable or a 
fixed length data element. Suitable lengths for a fixed 
length data element are in the range of about 1 - 12S 
bytes, while lengths in the range of about 24 - 96 bytes 
are preferred, with a length of about 64 bytes being more 
preferred. By way of example, if the network protocol is 
the well known transmission control protocol/Internet 
protocol (TCP/IP), then one address in the sei of ad- 
dressing information 502 may include a six byte data 
element wherein the first four bytes are the TCP/IP serv- 
er host network address, in network order, and the other 
two bytes are the TCP/IP server process network port 
number, also in network order. 

Another element of the object reference 500 of Fig 
5a. the incarnation number 504. is an identifier which 
prevents misdelivery ol ORB requests to the wrong des- 
tination in the event of address reuse. In other words. 
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even with the set of addressing information, which pin- 
points the server host address and the server process 
identification, it still is possible that the server process 
is not uniquely identified As discussed below, the incar- 

5 nation number of the present invention overcomes po- 
tential ORB misdeliveries. 

While a misdelivery may seem impossible at first 
glance, one must carefully consider how transient ob- 
jects and their host server processes are managed. 

10 Transient objects do not exist from process to process 
but rather cease when their server process ceases But. 
as those of skill in the art will understand, a running com- 
puter creates and deletes computer processes con- 
stantly, each of these processes having a specific net- 
work address. Therefore it is certain that one process 
may cease, thereby ceasing alt the unique transient ob- 
jects which exist within it and also freeing up a network 
address. This network address may be reused as there 
are typically only a finite quantity of process network ad- 

20 dresses available (32.768 or 32K is a typical number). 
Thus a request for a transient object which has ceased 
may be misdirected by the ORB if some other distin- 
guishing identification is not provided 

As the ORB is responsible for interpreting the incar- 

2S nation number 504. the ORB. and more specitically the 
object adapter (OA), is typically responsible for the as- 
signing of the incarnation number 504 This number can 
be arbitrary as long as it is distinguishable by the ORB. 
Vaiious embodiments of the incarnation number 504 are 

so contemplated. For example, assigning the incarnation 
number 504 some monotonically increasing value, such 
as a timestarnp. allows the ORB to distinguish between 
different processes which exist inconcurrently but hap- 
pen to receive the same address In other cases, it may 
be desirable to have two or more processes which are 
indistinguishable. In this case, identical incarnation 
numbers could intentionally oe assigned. Still further sit- 
uations may arise when it is desirable to have a prede- 
termined number such as 7ero be assigned to the incar- 

-io nation number 504. In any event, the incarnation 
number 504 may include a data element of fixed or var- 
iable length, depending upon the predetermined proto- 
col Suitable lengths for a frxed length data element are 
in the range of about 1-16 bytes, with lengths in the 
range of about 2 - 6 bytes being preferred and a length 
cf about 4 bytes being more preferred. 

As will be appreciated by those skilled in the art. the 
incarnation number, either as described in the above 
embodiment or in other embodiments, enables a distrib- 

?o tied object operating environment to flawlessly distin- 
guish transient objects. The incarnation number is novel 
to the present invention and allows the use of persistent 
^nd transient objects within a distributed object environ- 
ment 

The last listed element of the transient object refer- 
•~nce 530 ot Fig. 5a is the object key 506. In one embod- 
fioni object key 506 serves to distinguish between ob- 
■:>::$ within the server process Depending upon the pre* 
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determined protocol, the object key 506 may include a 
data element of fixed or variable length. Suitable lengths 
for a fixed length data element are in the range of about 
1 - 1 6 bytes : with lengths in the range of about 4 - 8 bytes 
being preferred and a length of about 6 bytes being more 
preferred. 

Fig. 5b shows a pictorial illustration of a persistent 
object reference 510 according to one embodiment of 
the present invention. The persistent object reference 
510 is an object which points to a persistent server ob- 
ject, and includes a kind field 511. a host name 512. a 
locator identification number (locator id) 514. an object 
key 516. and a sub-object identifier 518. As shown, the 
persistent object reference may also include an optional 
location hint 520. As discussed above with respect to 
Fig. 5a. kind field 511 isa data element which represents 
the object kind to which object reference 510 indirects. 
The host name 512 indicates a host computer which has 
a locator service (which is an entity such as a locator 
process or a locator object) responsible for maintaining 
the locations of target objects. For example, the host 
name 51 2 may include a network address, fn preferred 
embodiments the host computer indicated by host name 
512 has the target object resident therein. 

Referring next to the third listed element ol the per- 
sistent object reference 510 ol Fig. 5b. the locator id 514 
uniquely identifies the locator service on the host which 
is defined by the host name. In one embodiment the lo- 
cator id includes a hxed length data element. By way of 
example, one suitable embodiment of the locator id 514 
is a remote procedure call (RPC) program number for 
the locator. Those of skill in the art will be familiar with 
RPC protocols and the generation of RPC program 
numbers. In general, the RPC service will maintain a 
correspondence between a constant RPC program 
number and the desired server process addressing in- 
formation. That is. the RPC service is updated whenever 
the server process addressing information is changed 
Thus the distributed object system need not update the 
persistent object reference. In this case, the locator id 
514 may be a fixed length data element with a length of 
4 bytes. Turning next to the fourth element of Fig. 5b. in 
one embodiment object key 516 uniquely defines the 
target object with respect to the locator Hence the lo- 
cator uses the object key 516 to determine which de- 
sired target object is being requested. 

The combined data elements 512-516 constitute 
one example of what is known in the art as an "indirec- 
tion." An "indirection" is a set of information, a pointer, 
etc.. which directs the client entity to a source (such as 
a locator object) which can direct the client entity to the 
object. By way of a descriptive analogy, if a client re- 
quested geographical directions, an indirection would 
point the client to the location of a current map : or per- 
haps provide the client with a phone number of a geo- 
graphically astute individual. The idea of using an indi- 
rection (rather than direct addressing) is useful for per- 
sistent objects as these are mobile both from process 



to process and host computer lo host computer 

With continued reference to Fig. 5b. the sub-object 
identifier 516 is a data element typically used only by 
the target object lo manage finer grained objects. By 
5 way of analogy, a spread sheet may be an object, with 
the cells of the spread sheet being sub-objects. The 
granularity of objects, sub-objects and methods and ap- 
paratus for managing sub-objects are described in more 
detail in copending U.S. Patent Application Serial 
to Number (Attorney Docket No. P/71 7SUN1P023) enti- 
tled "METHODS AND APPARATUS FOR MANAGING 
COLLECTIONS OF OBJECTS", by Vanderbilt et. al.. 
which is incorporated herein by reference in its entirety. 
Another element optionally included in the persistent ob- 
'5 ject reference 51 0 is the location hint 520. The location 
hint 520 is an optional data element which provides de- 
tails regarding the last known location of the target ob- 
ject. The location hint 520 may also include an expiration 
timestamp. By way of explanation, the target object may 
20 have been called previously, thus the addressing infor- 
mation for the target object was retrieved at an earlier 
time. By using this location hint 520. the distributed op- 
erating system can avoid making the call to the locator. 
Of course, if the location hint 520 has expired or is not 
2S present, then the locator must be queried anyway. 

The embodiment of the present invention described 
above with respect to Figs 5a and 5b serves to wholly 
integrate the different kinds of object references into one 
disliibuled opeiahng environment framework. As de- 
30 scribed, the distributed object environment can distin- 
guish between the two primary kinds of object referenc- 
es and still maintain the advantages accorded to each 
kind 

Further integration occurs by utilization of the data 
elemonts provided by the present invention. For exam- 
ple, the object key in both transient and persistent object 
references may be used for transporting an object ref- 
erence formatted according to a first protocol of a first 
Distributed system into a 'second distributed system uti- 

j o h/mg a second protocol. This may be cone by formatting 
a second object reference according to the second pro- 
tocol and storing this m a variable length object key of 
the first object reference. Upon receiving the object ref- 
erence the second distributed system can strip out the 
cbject key and generate an object reference for the tar- 
get object wnich is in the proper format for the second 
cislnbuted system. Thus both transient and persistent 
cbject references can transfer across protocols by an 
identical mechanism the object key 

*o Still further evidence of the wholly integrated frame- 
work which the present invention provides can be found 
m considering the location hint of the persistent object 
reference data structure. As will be apparent, a suitable 
embodiment for the location hint may include a set of 

^ .-ddrossng information, an incarnation number, and an 
exDM-ino'-i date. In the case where the location hint is 
.•v --indole current, and valid, the persistent object refer- 
md reels to its persistent object by the exact same 



10 

BIMSDOCID: <EP 0737916A1_I_> 



19 



EP 0 737 916 A1 



20 



mechanism that a Iransienl object reference directs to 
its transient object. Not only is this combination effective 
for integrating the two kinds of object references, it lays 
the framework for a novel and cost effective method 
(with respect to system resource utilization) for calling 
persistent target objects, which method is: making calls 
to persistent distributed objects directly rather than 
through the use of a locator. 

While the disclosed embodiments of transient and 
persistent object references provide a few preferred 
frameworks for implementing the data structure aspect 
of the present invention, there are many other suitable 
embodiments. For example, in some embodiments the 
distributed operating system may update each and eve- 
ry object reference when a persistent object moves its 
location. Thus both persistent and transient object ref- 
erences may have direct addressing information, rather 
than the indirection described in the embodiment of the 
persistent object reference 510 of Fig. 5b. In a further 
example, some embodiments may eliminate direct ad- 
dressing completely, depending only on an indirection. 
In this case, the transient object reference may appear 
in a form akin to the persistent object reference 51 0. Still 
further embodiments would incorporate features re- 
quired by specific network communications protocols to 
enable operation under their particular framework. 

As will be apparent from the foregoing discussion, 
a distributed operating system which utilizes the afore- 
mentioned stiucluies foi objects, which include tran- 
sient and persistent objects, and transient and persist- 
ent object references, will have many advantages over 
the prior art. These advantages will be made clearer in 
the lollowing discussion of client-server interactions 
which utilize method aspects of the present invention 

Turning now to Fig. 6. a method 600 for implement- 
ing the client-server interaction in accordance with one 
embodiment of the present invention will be described 
The client-server interaction begins in a step 602 when 
the client invokes the server object (also relerred to as 
the target object). The client may be any suitable entity 
such as a client process or a client object. In a next step 
604. the client acquires addressing information regard- 
ing the server object. For example, the addressing in- 
formation acquired may include data such as described 
in the previous discussion of transient and persistent ob- 
ject references, it should be appreciated that this ad- 
dressing information may include a plurality of address- 
es from which one specific address is chosen. One cri- 
terion for choosing the address is to enable the fastest 
mode of transport between the client and the server. An- 
other common criterion for choosing the address is se- 
curity. Also, acquiring this addressing information may 
include various steps due to the fact that the information 
may be located at different sources. 

Once the addressing information is acquired in step 
604. the client, in a step 606. evaluates the addressing 
information to choose a specific address. In step 606 
the client may select an address based on different ra- 



tionale, including goals such as iransport speed be- 
tween client and server, load sharing, security, and/or 
concerns regarding the integrity of the addressing infor- 
mation. A more detailed illustration of one embodiment 

s of the substeps of step 606 is discussed below with ref- 
erence to Fig. 8. 

Continuing on through method 600 of Fig. 6. the cli- 
ent, in a step 608. sends the request to the address cho- 
sen in step 606. If the address is a remote address, step 

io 608 may include the steps of marshaling the chosen ad- 
dress together with the method and arguments, estab- 
lishing a network connection with the remote target ob- 
ject, and then making a remote call to the target object. 
As used herein, to "marshal" data is to format the data 

'5 in accordance with a predetermined network communi- 
cation protocol in preparation for network transmittal. In 
a step 610. it is determined if the client expects a re- 
sponse, and. if so process control is passed to a step 
612 wherein the client receives the response from the 

20 target object. Similar to step 608. if the target object is 
remote, then the client may "unmarshal" the response 
from target object, i.e. the data is translated from a pre- 
determined network communication protocol into a for- 
mat meaningful to the client. Alter receiving the re- 

25 sponse. or if no response is expected, control proceeds 
to a step 614 upon which the client-server interaction of 
Fig. 6 is complete. 

Referring now to Fig. 7. a more detailed description 
ol step 604 in accordance with one method aspect of 

30 the present invention will be described. As will be ap- 
preciated by those of skill in the art. the method of Fig 
7 is generally for use in a distributed object system uti- 
lizing the object references of Fig. 5a and 5b or similai 
object references. However, as will be apparent, the 

3$ scope of the present invention includes other embodi- 
ments of step 604 which are more suitable for additional 
embodiments of object references. 

The flow chan of Fig 7 begins in a step 702 when 
control is passed to step 604 of Fig 5 The initial sub- 

•*o slantive step of Fig. 7. step 704. determines if the object 
kind is transient. As discussed above in reference to 
Figs. 5a and 5b the object kind determination can be 
accomplished by various methods such as examining 
the internal name In the case where the object kind is 

J 5 transient, control branches to a step 705 where the ad- 
dressing information is returned directly from the object 
reference. This is possible because a transient object 
reference in accordance with Fig. 5a has direct address- 
ing information, as opposed to an indirection. Once the 

so addressing information is returned in step 706. control 
is passed to a step 708 where the acquire addressing 
information step 604 is complete. 

Following down the other branch of step 704 if the 
object kind is not transient, control is passed to a step 

55 710. where it is determined if the object kind is persist- 
ent. If the object kind is not persistent (the object is null 
or invalid), control is passed to a step 712 wherein an 
error message is generated and step 604 is complete. 



11 



21 



EP 0 737 916 A1 



22 



As should be apparent, if the object is neither transient 
nor persistent., it is improper to send a request to the 
target object (as it is either null or invalid) and thus an 
error message is appropriate. 

On the other hand, if in step 710 it is determined s 
that the object kind is persistent, then in a step 714 a 
memory cache-1 is checked to see if the target object 
addressing information is resident therein. If so. control 
proceeds to a step 720 where the addressing informa- 
tion is returned directly from cache-1 and then on to step to 
705 where step 604 (which acquired addressing infor- 
mation) is complete. The cache memory may be any 
suitable memory such as local RAM 38 described in ref- 
erence to Fig. 2. Storing and retrieving the addressing 
information in memory cache-1 allows for direct and is 
speedy access to this information. 

If the addressing information is not resident in 
cache-l . control proceeds to a step 716 were the client 
obtains the addressing information. Typically the ad- 
dressing information is obtained in step 716 by means 20 
ol an indirection utilizing a locator service as described 
previously with reference to Figs. 5a and 5b. One em- 
bodiment of step 716 will be described in more detail 
below with respect lo Fig. 9. After the addressing infor- 
mation is obtained in step 716 it is stored in cache-1 in 25 
a step 718. thereby perpetuating the efficiency of this 
method. Additionally, another mechanism for increasing 
the addressing information available in cache-1 will be 
desciibed below in refeience lo Fig. n. Then, in a step 
720. the addressing information is returned from cache- 00 
1 and control is passed lo a step 708 v/here the acquire 
addressing information step 604 is complete. 

One embodiment of the choose address slep 606 
of Fig. 6 will now be described in further detail with re- 
spect to Fig. 8. This embodiment serves primarily to se- ^ 
lect the addressing information which will provide the 
fastest mode of transport between the client and the 
server The three different modes of transport described 
herein are (in descending order of transporl speed) lo- 
cal, shared memory, and remote transport. Local trans- -to 
pon occurs within the same process and is performed 
by copying data within the same address space. Shared 
memory transport (may also be called "same host") is 
performed using the host operating system inter-proc- 
ess communication procedures. Remote transport is 4 & 
performed using networking facilities. Each of these 
may vary depending upon factors such as the operating 
system and the network communication protocol. The 
design and implementation of local, shared, and remote 
transport will be familiar to those skilled in the art. so 

The flow chart of Fig. 8 begins in a step 802 when 
control is passed to step 606 of Fig. 6. Then, in a step 
804. it is determined if the target object is running in the 
client process. If so. then in a step 806 the local address 
and local transport are selected toconnect the client and ss 
server. On the other hand, if the target object does not 
run in the client process, then in a step 810 it is deter- 
mined if the server object is running on the same host 



as the client and if shared memory addressing informa- 
tion is available. If so, then in a step 8 1 2 shared memory 
addressing and shared memory transport are selected 
to connect the client and server. Otherwise, if the target 
object is resident neither in the client process nor in the 
client host, a stop 814 selects the remote address and 
remote transport to connect the client and server. In any 
event, after the addressing has been selected, control 
is passed to a step 808 wherein step 506 of Fig. 6 is 
complete. 

Referring next to Fig 9. one embodiment of step 
716 of Fig. 7 is described in more detail. The method of 
Fig. 9 begins in a step 902 when the get addressing step 
716 receives control. Next, in a step 904. the transient 
object reference for an ORB daemon process is ob- 
tained by way of the locator id and the host name. In 
one embodiment, an ORB daemon process is resident 
on each computer system of the distributed object en- 
vironment. The ORB daemon specifically found in step 
904 is a process running in the background on the server 
host computer, under which a locator object is active. 
Daemon processes are well know to those of skill in the 
art Next in a step 906 the client calls the locator object 
to invoke a look-up method, passing arguments includ- 
ing the object key for the target object In response, the 
ORB daemon will return direct addressing information 
for the target object. In preferred embodiments the dae- 
mon process wilt additionally verify the stale of the serv- 
ei piocess. stalling the piocess if necessaiy One pre- 
ferred embodiment of server process startup can be 
found in Vanderbilt et. al.'s copending U.S. Patent Ap- 
plication Serial Number (Attorney Docket No 
P747/SUN1P030) entitled "METHODS AND APPARA- 
TUS FOR MANAGING COMPUTER PROCESSES" 
which is incorporated herein by reference in its entirely 
After the direct addressing information is received, con- 
trol is passed to a step 908 wherein step 716 of Fig 7 
is complete 

Turning nexl to Fig. 1 6. one embodiment of step 904 
of Fig. 9 is described in more detail. The method of Fig. 
10 begins in a step 1002 when the get transient object 
reference for ORB daemon step 904 receives control. 
In a step 1004. it is determined if the transient object 
reference for the ORB daemon is resident in a memory 
cache-2. If so. control branches to a step 1 01 2 where 
the transient object reference for the ORB daemon is 
returned directly from cache-2. After the transient object 
reference is returned, control is passed to a step 1014 
wherein step 904 of Ftg. 9 is complete. 

If the transient object reference for the ORB dae- 
mon is not resident in cache-2. the control branches to 
a step 1006. wherein the client calls the remote proce- 
dure call (RPC) binder on the server host, passing the 
locator id and the incarnation number as arguments to 
the call. In response, the RPC binder returns addressing 
information and in a step 1005. the client constructs the 
transient object reference utilizing the returned ORB 
daemon addressing information. Implementation and 
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construction of the RPC binder are well Known to ihose 
skilled in the art. Once the transient object reference has 
been constructed, the client stores it in cache-2 in a step 
1 01 0. thereby perpetuating the efficiency of this method. 
Then control is passed to a step 1012 where the tran- 
sient object reference for the ORB daemon is returned 
directly from cache-2. After the transient object refer- 
ence is returned, control is passed to a step 1014 where- 
in step 904 of Fig. 9 is complete. 

One method for increasing the addressing informa- 
tion available in cache-1 will be described now with ref- 
erence to Fig. 11. By way of background, an object ref- 
erence for a persistent object may have an optional lo- 
cation hint (asdescribed in reference to Fig. 5b and else- 
where). The location hint includes direct addressing in- 
formation for a target object. Thus each location hint has 
the addressing information step 714 of Fig. 7 is looking 
for in cache-1. Furthermore, as will be appreciated by 
those skilled in the art. object references may be re- 
ceived by a host computer either through an object call 
or in response to an object call. Thus there is the poten- 
tial to increase the addressing information every time an 
object reference is received. 

In the method of Fig. 11. a first step 1100 unmar- 
shals an object reference which has been received lor 
any reason such as the two mentioned in the preceding 
paragraph Then, in a step 1102. it is determined if the 
object reference has a location hint. If so. in a step 1 104. 
the addiessing information and an expiialion dale iif 
present) from the location hint is stored into cache-1. If 
there is no location hint, or subsequent to updating the 
cache-1. the method of Fig. 11 is done in a step 1106 
and the object reference can be used for its originally 
intended purpose. 

In another method aspect of the present invention, 
one closely related to the method of Fig. 11 the separate 
computers of the distributed object operating environ- 
ment work together to share addressing information 
Therefore, when one computer uses a locator service 
to obtain addressing information about a target object, 
this computer may in turn distribute this information 
along to the other computers of the distributed object 
operating environment. One suitable way to pass this 
information would be by way of an object reference. 
Then each computer would store this addressing infor- 
mation along with an expiration date into its cache-1 
memory. 

One further advantage of the present invention can 
now be discussed. As will be appreciated by those of 
skill in the art. one model (useful for the present discus- 
sion) divides the ORB into three different abstract levels, 
defined herein as the Application Level ORB. the Trans- 
port Level ORB. and the Communication Level ORB. 
Components representative of the lower Communica- 
tion Level ORB would include the activities of the 
shared, local, and remote addressing and transport dis- 
cussed above with respect to Fig. 8. Components rep- 
resentative of the upper Application Level ORB would 



include the initial client call to a server, wherein the lo- 
cation and object kind of the server was opaque to the 
client. The middle level, the Transport Level ORB. is the 
only portion of the ORB which must to be concerned with 

5 the kind of the server object. Thus the present invention 
accomplishes the task of integrating transient and per- 
sistent objects within a distributed object environment 
without introducing an undue burden throughout the 
ORB. thereby ensuring the efficiency of the distributed 

to object environment. 

Although only a few embodiments of the present in- 
vention have been described, it should be understood 
that the present invention may be embodied in many 
other specific forms without departing from the spirit or 

'5 scope of the invention. The client-server models dis- 
cussed with reference to Figs. 3a - 3b are only samples 
and in no way should be construed as limiting. By way 
of example, the "host-to-host" model could be extrapo- 
lated to include multiple target objects. That is. the first 

20 target object 304 could simply be an object reference 
which mdirects to another target object, perhaps in an- 
other distributed object environment. Or. the first target 
object could perform a portion of the requested service 
and then make its own call to a second target object be- 

25 (ore responomg to the first client 302. As will be appre- 
ciated, the possible enumerations take on many embod- 
iments, all of which fall within the scope of the present 
invention. 

Still further the data stiucluies of Fig. 5a and 5b 

oo may be varied gieatly and yet fall within the scope of the 
present invention As a first example, data structures for 
both transient and persistent object references could be 
embodied without the kind field. Still further examples 
can be found by contemplating the multiplicity of net* 

3$ work communication protocols, operating systems, and 
applications programs. Each of these may require a 
specific arrangement of the described data structures. 
Construction and implementation of each of these nu- 
merous embodiments will be apparent to those skilled 

■to in the an and. accordingly, fall within the scope of the 
present invention. 

As will be appreciated by those skilled in the art of 
distributed object systems, the underlying ideas behind 
the described methods of handling transient and per- 

4 $ sistent objects can be implemented in a wide variety of 
alternative embodiments, of which there far too many to 
discuss in detail However, since the underlying philos- 
ophy has been described, various alternatives will be 
obvious to those skilled in the art. By way of example. 

so the method of selecting a transport mode, one embod- 
iment which was described with respect to Fig. 8. may 
have many variations. The selection criterion could em- 
phasize a load sharing desire, thus a remote address 
may be the best address under this criterion. From an- 

55 other aspect, there may be different forms of transport 
not described. However if other forms of transport are 
available, those of skill in the art will understand how to 
apply the teaching of the present invention to utilize 
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these other modes of transport. 

Therefore, the present examples are to be consid- 
ered as illustrative and not restrictive, and the invention 
is not to be limited to the details given herein, but may 
be modified within the scope of the appended claims. 



Claims g 

1. An object for use as an object reference for a tran- to 
sient object, said transient object intended to reside 
in a server computer process executing on a server 
computer system in a distributed object operating 
environment contemplating a plurality of distributed 
transient objects, said object having a data struc- 
ture comprising: 10. 

a set of endpoint addresses corresponding to 
said server computer system; 



tribuled object operating environment includes a cli- 
ent resident in a client computer process executing 
on a client computer system and said set of end- 
point addresses and said incarnation number to- 
gether indicate that said server computer process 
is said client computer process. 

An object as described in claim i wherein the dis- 
tributed object operating environment includes a cli- 
ent resident in a client computer process executing 
on a client computer system and said set of end- 
point addresses and said incarnation number to- 
gether indicate that said server computer system is 
said client computer system. 

An object as described in claim 1 wherein said in- 
carnation number is a data element of variable 
length. 



20 

an incarnation number corresponding to said 
server computer process: and 

an object key corresponding to said transient 
server object. 25 

such that said set of endpoint addresses, said 
incarnation number, and said object Key 
uniquely identify and locale said transient serv- 
er object. 30 

A object as described in clatm 1 v/herein said data 
structure further includes a kind field indicating that 
said transient object kind is transient. 



11. An object as described in claim 10 wherein said in- 
carnation number is a data element of fixed length. 

12. An object as described in claim 11 wherein said in- 
carnation number is a data element in the range ol 
1 - 16 bytes long. 

13. An object as described in claim i wherein said in- 
carnation number is a number indicating the crea- 
tion time of said server computer process. 

14. An object as described in claim 1 wherein said in- 
carnation number is a predefined number which has 
a predefined meaning to the server computer proc- 
ess 



4. 



3. An object as described in claim 1 wherein said set 
of endpoint addresses is a data element of variable 
length 

An object as described in claim 1 wherein said set io 
of endpoint addresses is a data element of fixed 
length. 

An object as described in 4 wherein one address of 
said set of endpoint addresses is a data element in is 
the range of 24 - 128 bytes long. 

An object as described in claim 5 wherein 4 bytes 
of said one address is a server computer system 
network address and 2 bytes of said one address so 
is a server computer process network port number. 

7. An object as described in claim 1 wherein said set 
of endpoint addresses includes a server computer 
system network address and a server computer s$ 
process network port number. 

8. An object as described in claim 1 wherein the dis- 



6. 



15. An object as described in claim 1 wherein said ob- 
ject key is an identifier wnich in conjunction with said 
set of addressing infprmation and said incarnation 

* number uniquely defines said transient server ob- 
ject. 

1 6. An object as described in claim 1 5 wherein said ob- 
ject key is a identification number unique within said 
server computer process. 

17. An object as described in claim 1 wherein said dis- 
tributed object operating environment is a first dis- 
tributed object operating environment, and wherein 
said object key includes a second object for use as 
a second object reference for a transient object of 
a second distributed object operating environment. 

18. An object as described in claim 17 wherein said ob- 
ject key enables a client in said first distributed ob- 
ject operating environment to call said transient ob- 
ject of said second distributed object operating en- 
vironment. 
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1 9. A transient server object corresponding to an object 
reference as described in claim 1. said transient 
server object having transient state associated with 
it. said transient state stored in transient memory 
on said server computer system. 

20. A transient server object as recited in claim 19 
wherein said transient server object is bound direct- 
ly to said server computer process such that when 
said server computer process ceases, said tran- 
sient server object ceases to exist 
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a set of endpoinl addresses corresponding to 
said second server computer system upon 
which said persistent server object resides: and 

5 an incarnation number corresponding to said 

second server computer process. 

such that said set of endpoint addresses, said 
incarnation number, and said object key 
to uniquely identify and locate said persistent 

server object. 



21. A distributed object operating environment com- 
prising: 

a plurality of computer systems: 

a computer network interconnecting said plu- 
rality of computer systems: and 

at least one object as recited in claim 1 . said at 
least one object residing on one of said plurality 
of computer systems. 

22. A distributed object operating environment as de- 
scribed in claim 21 further including a second object 
for use as an object reference for a persistent ob- 
ject, said persistent object intended to reside in a 
second sei ver process executing on a second seiv- 
er computer system, said second object having a 
data structure including: 

a computer system name corresponding to a 
computer system on which a locator service ex- 
ists: 

a locator identification corresponding to a dae- 
mon computer process under which said loca- 
tor service resides: 

an object key corresponding to said persistent 
object: and 

a subobject identifier. 

23. A distributed object operating environment as de- 
scribed in claim 22 wherein said data structure of 
said second object further includes a kind field indi- 
cating that the kind of said object is persistent. 

24. A distributed object operating environment as de- 
scribed in claim 22 wherein said data structure of 
said second object further includes a location hint. 

25. A distributed object operating environment as de- 
scribed in claim 23 wherein said location hint in- 
cludes: 



26. A distributed object operating environment as de- 
scribed in claim 22 further including: 

75 

a third object kind for use as an object reference 
for a null object: and 

a fourth object kind for use as an object reler- 
20 ence for an invalid object. 

27. An object for use as an object reference for a per- 
sistent object, said persistent object intended to ie- 
side in a server computer process executing on a 

2S server computer system in a distributed object op- 
erating environment contemplating a plurality of dis- 
tributed transient objects, said object having a data 
structure comprising: 

oo a computer system name corresponding to a 

computer system on which a locator service ex- 
ists: 

a locator identification corresponding to a dac- 
3$ mon computer process under which said loca- 

tor service resides - 

an object key corresponding to said persistent 
object' 
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a subobject identifier: and 

a location hint. 

28. An object as described in claim 27 wherein said lo- 
cation hint includes: 

a set of endpoint addresses corresponding to 
said server computer system: and 

an incarnation number corresponding to said 
server computer process. 



such that said set of endpoint addresses, said 
ss incarnation number, and said object key 

uniquely identify and locate said persistent ob- 
ject. 



so 
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29. An objecl as described in claim 28 wherein said 
computer system on which a locator service exists 
is said server computer system. 

30. An object as described in claim 27 wherein said da- s 
ta structure of said object further includes a kind 
field indicating that the kind of said persistent object 

is persistent. 

31. A distributed object operating environment com- w 
prising 

a plurality of computer systems: 

a computer network interconnecting said plu- i$ 
rality of computer systems; and 

at least one object as recited in claim 27. said 
at least one objecl residing on one of said plu- 
rality of computer systems. so 

32. A persistent server object corresponding to an ob- 
ject reference as described in claim 27. said persist- 
ent server object having persistent state associated 
with it. said persistent state stored in persistent 
memory on said server computer system. 

33. A persistent server object as recited in claim 32 
wheiein said persistent server object is opeiable lo 
persist such that when said server computer proc- oo 
ess ceases, said persistent server object maintains 
its state 

34. A computer implemented method for maintaining 
distributed object addressing information in a cache 
memory on a computer system, said computer sys- 
tem for use in a distributed object operating envi- 
ronment said method comprising the steps of- 

receiving under computer control an object ref- 
erence, said object reference corresponding to 
a distributed object: and 

determining under computer control if said ob- 
ject reference includes addressing information 
corresponding lo said distributed object and. if 
so writing under computer control said ad- 
dressing information into said cache. 

35. A method as recited in claim 34 wherein said step so 
of receiving an object reference further includes a 
step of unmarshaling under computer control said 
object reference. 

36. A method as recited in claim 35 wherein said step ss 
of receiving an object reference is part of a target 
object call. 
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37. A method as recited in claim 35 wherein said step 
of receiving an object reference is part of a re- 
sponse to a target object call. 

38. A method as recited in claim 34 wherein said step 
of writing said addressing information includes writ- 
ing under computer control an expiration date for 
said addressing information into said cache. 

39. A computer implemented method for calling a dis- 
tributed server object which is intended to reside on 
a server process executing on a server computer 
system, said server object having a corresponding 
object reference which resides tn a client process 
executing on a client computer system, said method 
comprising the steps of 

acquiring under computer control addressing 
information for said distributed server object 

selecting under computer control an address 
for said distributed server object: and 

sending under computer control a request tc 
said distributed server object. 

40. A method as recited in claim 39 further including the 
step of receiving under computer control a re- 
sponse. Iiom said distributed server object 

41. A method as recited in claim 39 wherein said step 
of acquiring addressing information includes the 
subslep of determining under computer control the 
kind of said distributed server object, said kinds in- 
cluding Iransient and persistent. 

42. A method as recited in claim 41 wherein said kinds 
further include null and invalid and wherein saici 
step of acquiring addressing information further in- 
cludes the substep of returning under computer 
control an error message if the kind of said distrib- 
uted server object is null or invalid. 

43. A method as recited in claim 41 wherein said step 
of acquiring addressing information further includes 
the substep of returning under computer control 
said address information directly from said object 
reference if the kind of said distributed server object 
is transient. 

44. A method as recited in claim 41 wherein said step 
of acquiring addressing information further includes 
the substeps of: 

determining under computer control if said ad- 
dress information is stored in a cache memory 
located on the client computer system: and 



16 

BIMSDOCID; <EP 0737916A1_I_> 



* 



31 

returning under computer control said address 
information from said cache memory if the kind 
of said distributed server object is persistent. 

45. A method as recited in claim 44 wherein it is deter- 5 
mined that said addressing information is not initial- 
ly stored in said cache memory and. as a result, the 
step of acquiring addressing information further in- 
cludes the intermediate substeps of: 

10 

obtaining under computer control said address- 
ing information from within said distributed ob- 
ject operating environment: and 

storing under computer control said addressing is 
information in said cache memory. 

46. A method as recited in claim 45 wherein said object 
reference includes a locator identification, a host 
name, and an object key. and wherein said step of 20 
obtaining said addressing information includes the 
substeps of: 

establishing under computer control computer 
communications with a daemon process run- 25 
nmg on the server computer system: and 

issuing under computer control a look-up oper- 
ation to said daemon piocess. passing said ob- 
ject key to said daemon. 00 

47. A method as recited in claim 46 wherein said step 
of establishing computer communications with a 
daemon process includes the step of determining 
under computer control if a transient object refer- 35 
ence for said daemon is stored in a cache memory 
found on saidclient computer system and. if sc. said 
step of establishing communications further in- 
cludes the step of returning under computer control 
said transient object reference from said cache -*o 
memory. 

48. A method as recited in claim 47 wherein it is deter- 
mined that said transient object reference is not 
stored in cache memory and. as a result, said step 4 * 
of establishing communications with a daemon 
process further includes the intermediate steps of: 

calling under computer control a remote proce- 
dure call binder on the server computer system so 
using said host name, said calling step includ- 
ing passing said locator identification with a 
predetermined incarnation number: 

receiving under computer control an address ss 
from said remote procedure call binder call: 

constructing under computer control a transient 
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object reference for said daemon, said tran- 
sient object reference constructed from said 
address and said predetermined incarnation 
number: and 

storing under computer control said transient 
object reference in said cache memory. 

49. A method for calling a distributed server object as 
recited in claim 39 wherein said step of selecting an 
address includes the step of determining under 
computer control if said server process and said cli- 
ent process are the same process. 

50. A method as recited in claim 49 further including the 
step of selecting under computer control a local ad- 
dress and a local transport if said client process and 
said server process are the same process. 

51. A method as recited in claim 49 wherein it is deter- 
mined that said client process and said server proc- 
ess are not the same process and said method fur- 
ther includes the steps of 

determining under computer control if said 
server computer system is the same as said cli- 
ent computer system 

selecting under computet control a shared 
memory address and a shared memory trans- 
port if said server computer system is the same 
as said client computer system: and 

selecting under computet control a remote ad- 
dress and a remote transport if said server com- 
puter system is not the same as said client com- 
puter system 

i 

52. A computer implemented method for maintaining 
addressing information for a distributed object in a 
plurality of caches, each cache resident on a corre- 
sponding computer system each computer system 
for use in a distributed ob|ect operating environ- 
ment, said method including the steps of 

distributing under computer control all address- 
ing information for distributed objects available 
m said plurality of caches, said all addressing 
information distributed in the form of a plurality 
of object references sent to at least one com- 
puter system: and 

said at least one computer system performing 
the computer implemented method of claim 34 
for the distributed plurality of object references. 
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